Interview with Algorithm/Algotech - by irwin
Translation by Dely/Blowjobb

---
irwin: Hello Algorithm! Please introduce yourself. List your computers and tell us why C64 is closest to you :)

Algorithm: The C64 was my first "proper" computer. Previous to that, I was using the DIY computer kits with hex display etc. I had a C64 when i was 14 (In 1990) and it was such a lovely experience. The C64 package that I had was "The Hollywood Pack" and the first game i played on it was "Platoon" great game considering the early times it was created in (I believe it was 1987).
During this period, most of the time it was mainly playing games but after around 2 years or so, i delved into the programming side. Starting by using hex codes via typed up assembler and then coding everything via Action Replay Cartridge and Tape Deck (Please excuse the extremely crap programmes i created in the 90's).
In a nutshell, the reason why i would say that the c64 is closest is because its limitations always seem to be removed time and time again due to the heavy motivation from other coders to "increase its capability". Its also great to be able to create something that has not been done before on a machine created in the early 80's. 

---
irwin: At CSDB I noticed, that besides retrocomputers you are interested in three things: video compression, C64 graphics and... naked girls :) The last topic is very interesting and intriguing, so... let's start our talk on compression topic. What is the origin of your interest in compression? I noticed that you wrote this type of demos, applications not only for C64 but for Amiga too?

Algorithm: Well.. Originally when i started on the c64, i had no idea on compression. The only compression method i used was runlength encoding for one of my demo parts at around 1995 or so. It was during the Amiga times that i was actually interested in compression and delved more into it. The SNS (scale and smooth) routine was used in my "Spice" demo (which reads chunky data and this points to lookup planar data pointing to interpolated image data). Although many other more efficient methods could have been used instead. "The Taylor Dayne" demo also demonstrated real time ADPCM3 decoding on a 7 MHz amiga decoding over 20000 samples per second (although this could have been optimised further).

As for naked woman... mmmmm. This is my addiction :-)

---
irwin: On Atari scene lot of people doesn't know about difficulties connected with audio-video compression. When we are watching short animations or, for example, achievements of Mahoney at C64, we are hearing complainments at quality. We are excited on n-th version of gouraud-shaded cube or plasmas by the compression isn't interesting for us. Does the C64 scene knowledge is on higher level or there is some people who complains about too low framerate, too few colors, too big pixels etc. How the audio-video compression topic is received by C64 scene?

Algorithm: Well. Some people dont know the internal methods that are required in order to create something. Someone can create a new gfx mode but any people that see this that dont realise what is involved to create such a mode (or whats involved in order to convert etc) would just say its rubbish and that PC VGA looks better etc.
Furthermore, If you remember when "State of the Art" by Spaceballs on Amiga was created, there were a considerable amount of people which stated that the demo was poor etc. They did not take into consideration that the demo was one of its kind and i would say a 'first' in regards to a proper music video demo. Using vector plotting to animate dancers was unique and even now it seems the hype (with the Apple Ipod advertisements etc).
I guess it depends on the person watching the demo. For example, creating a 4x4 effect on a c64 (eg zoomer etc) can either be frowned upon (as its a blocky effect) or held with inspiration (due to the code to calculate zoomer etc).
The audio / visual compression i believe is not received with too much respect in the C64 scene. Many people look at the overall outcome of the effect. Eg. If one was to create a shadow dancer routine which lasts for 10 seconds at twice the quality, they would frown on one which lasts for 30 seconds at half the quality but uses the same storage space (which would indicate possibly more code do compress data more heavily etc).

---
irwin: In your upcoming CSAM v2 - application for video compression with the use of charsets - are you going to use new ideas and new compression algorithms, for example "Pairwise Nearest Neighbor" for similar chars detection. What is the difference between v2 and older, familiar to us v1?

Algorithm: CSAM V2 is completely difference in the sense that it achieves the following (over CSAM V1)
CSAM V1 does not merge similar block area's (to allow same char to be used on multiple area's) producing less error.
The Codebook generation method uses the same prune technique (but also other methods) but the clustering is the major addition which concentrates similar blocks throughout the entire video to one of 256 codebooks and finally merges them with several iterations.
The PNN method is used in another test tool but i may plan on adding it to the CSAM Tool.
I have other idea's but this is non related to vector quantisation. more in regards to Genetic compression.

---
irwin: What Atari users can expect? Will the v2 take into account specific Atari capabilities such as 64 or 128-char charset or 240 lines of screen?

Algorithm: Well. CSAM V2 allows the user to chose the amount of codebooks so its no issue to create 64 codebooks or 128 etc. 240 lines is not supported at the moment but no problem to implement.

---
irwin: Will the application be more user friendly? Personally, I could use an option for loading series of pictures or frames and batch saving in BMP or PNG. 

Algorithm: The application can now load AVI files but batch saving is not supported yet.

---
irwin: ADCPM formatted soundtrack was for the first time used in Amiga in your demo. For C64 or Atari this is still too much of data. Mahoney recently showed innovative compression technique, which allows to pack about 2 minutes of voice in 40 KB. I know, that this is subject of your interest - is there a possibility to compress not only human voice frequencies but music too?

Algorithm: Certainly. If you look at one of my audiovq tests on CSDB, i can compress around 2 minutes of audio into 10k! I am working on a music compressor which can fit around 2 minutes in 40k (and this works on any type of audio file - eg music, rock etc).
My forthcoming audio routine utilises a hybrid VQ/Dynamic Delta modulation routine where optimum chunks are selected and merged. these are then dynamically delta compressed to 2 bits per sample and then reindexed. This method, I can have 128k of codebook data in 32k and the rest for the lookup info.

---
irwin: Let's talk about other interesting thing, namely the use of hardware sprites for coloring static pictures. You are the author of few converters which are using this technique, the latter one produces really outstanding pictures, even comparable with NUFLI although it uses much less CPU cycles, allowing for example to create game in this mode. What can we expect in the future - I'm thinking about MUCSU-FLI. Can you tell us something about this mode, how the screen is constructed?

Algorithm: Ok. I remember posting comparison pics between NUFLI and MUCSU and ofcourse NUFLI produces less errors in the converted image, but it should as it uses full processing power (sprite color changes, FLI per 2 lines etc) in comparison with MUCSU which only changes sprites per 21 lines. In previous posts, i was merely comparing quality in comparison with the complexity of the mode and many images were not that much poor in comparison to NUFLI etc
Now MUCSU-FLI i can say that this mode is the ultimate (at the time of writing) as not only does it allow FLI per line, but also sprite underlay at a width of 240 pixels). Please see example picture on CSDB (with C64 example). Ofcourse conversion can be honed to produce less errors.

---
irwin: As you may know, on Atari scene creating pictures with the use of sprites is very limited, only one simple bmp to sprite converter exists (that one, which is included in G2F). So I'm asking you, person who is in my opinion the best expert in this topic, if there is a possibility to create such converter, having in mind very limited capabilities of Atari hardware sprites. If yes, are you going to create such converter for Atari, which will be using sprites as well as color changes during line drawing.

Algorithm: The Atari has a lot of potential. Its just a pity that the potential has not been realised as on the c64. I would only need to know the limitations of the atari sprites and it would not be an issue to create a converter. Although codewise for Atari, you would need to create a runnable prog from it as i have no clue on anything atari related.

---
irwin: What do you think about Atari 8-bit scene. About demos, music and the graphics. What, in your opinion, missed in our demos in comparison with C64's?

Algorithm: I believe the Atari has a lot of potential, but there seem to be less gfx / audio trickery (in comparison with the C64 where there have been a wealth of it (eg vsp, fli, 8 bit audio, SHIFLI, NUFLI etc).

---
irwin: Thanks for your time, I wish you successes with your future projects for C64 and... I hope that not only for the C64. 

Algorithm: Thank you. 
--------

irwin & Dely - february 2011